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(57) Abstract: The present invention provides a system for creating an application software environment without changing an 
operating system of a client computer, the system comprising an operating system abstraction and protection layer, wherein said 
abstraction and protection layer is interposed between a running software application and said operating system, whereby a virtual 
environment in which an application may nin is provided and application level interactions are substantially removed. Preferably, 
any changes directly to Uie operating system are selectively made within the context of the running application and the absu-action 
and protection layer dynamically changes ihe virtual environment according lo administrative settings. Additionally, in certain em- 
bodiments, the system continually monitors the use of shared system resources and acts as a service to apply and remove changes 
10 system components. The present thus invention defines an "Operating System Guard." These components cover the protection 
semantics required by DLLs and other shared library code as well as system device drivers, fonts, registries and other configuration 
items, files, and environment variables. 
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OPERATING SYSTEM ABSTRACTtON AND PROTECTION LAYER 

This application is a contfamation-m-part of U.S. Patent A^rplication No. 

09/456,181 ^ the eoiirety of wluch is incorporated herein by reference as if fully 

setfoitk 

The present invention relates to conq)uter sojlware, and more particularly to 
operating system software. 

BACKGROUND OF THE INVENTION 

In many mvironm^ts;, but particularly in enviranments Tvbere an application is 
delivered via a network, the most ing)ortant feature is an ability to run applications on the fly, 
without a complex installation. Typically, in certain prior art systems, great pains were taken 
to modify a cKent system to appear as if a program was installed, or to actually install the 
software itself and then back ont these modifications to restore the ozignial conflguratbn. Bi 
domg this, multiple problems presoit themselves: conflicts between an application and the 
con5)uter's current configuration, mult^le instances of the same or different appficationsi, 
conq^lexity oftheback outprocessrequhesan q)pHcationtobeputfhrougJi aiigara 
to ensure all of its modifications can be accounted for, and the use of shared files and system 
con^onents by muk^le applications complicates back out and the installation process. 
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SUMMARY OF THE INVENT 



The present invention provides a system for a:eating an application software 
environment widiout changing an operating system of a cfient coniqputer, the system 
con^rising an operating system abstraction and protection layer, \^ilerein said abstraction 
and protection layer is mteiposed between a rmming software application and said 
operating system, vsiiereby a virtual enviromnent in which an q>plication may run is 
provided and application level interactions are substantially removed. Preferably, any 
changes directly to the operating system are selectively made ^vithin the context of the 
running application and the abstraction and protection layer dynamically changes the 
virtual environment according to administrative settinjgs. Additionally, in cotain 
embodiments, the system continually monitors the use of glared system resources and 
acts as a service to apply and remove changes to system conqsonents. 

Thus, for exanq)le, in embodiments within Windows-based operating systems, 
and wherein all operations to the Windows Registry are through the Win32 API, the 
system preferably provides a means for hookmg fbnctions, whereby each time said 
functions are invoked another iimction or application intercepts the call, and the system 
most preferably hooks each appropriate API fimction to service a request whether made 
by an application run &om a server or if made by an application against a configuration 
key being actively managed 

In other preferred embodiments of the present invention, additional functionality 
is provided, such as those embodiments wherein the operating system abstraction and 
protection layer manages the integration of multiple instances of an application by 
recogttizmg how many instances of an application are running, and in such embodiments 
most preferably it also avoids making changes on startup and shutdown unless there is 
only one application instance running. In this embodiment it is also possible to support 
multi-us^r operating systems in which multiple instances of an application can be rumung 
on behalf of different users. 
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Thus^ the operating system abstraction and protection layer presents an 
environment to an appKcation that appears to be an installation environment without 
performing an installation, whereby a '^seudo installation" is created in which all of the 
settings are brought into a viitaal environment at the time fhe^^ Qrintiie 
case of an installed application, acts to dynamically modify fhe behavior of the 
application at nm-time. Preferred embodiments provide a means for preventing 
information on the client conqsnter j&om interfering or modifying the behavior of an 
appfication, and most preferably provide a means for dynamically changing tlie virtual 
environment according to administrative settings. As mentioned above, in certain 
embodiments it will be possible to have more than one instance of a single soflware 
application running on the same client conq)nter, even if it was not origmally authored to 
do. so. In sudi embodiments, shared, coirtroUed contexts are provided in which at least 
two of said instances of a single appUcation share one or niore virtual settm . 

BRIEF DESCRIPTION OF THE DRAWINGS 

HQ. 1 is a block diagram sdiematic showing the relative reladondiq) of the present 
invention, an operating system and a soflware application; 

FIG. 2 is a block diagram schematic showing 

HG. 3 is ablock diagram schematic lowing 

H6. 4 is a bbdc diagram schematic ^o^ving 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Referring now to FIG. 1, there is illustrated a block diagram SGheroatic showing the 
relative relationship of the present invCTtion, an operating system a|id a sofiware application. 
Preferred embodiments of the present invention provide an operating system abstraction and 
protection layer 100 denommated an ''Operating System Guard'' Xatemally, many operating 
systems 10 provide &vJt domains to protect appHcations 50 from aJQfectmg each other when 
ran. However, shared system resources and many other operating system featm^s allow this 
protection domain to be conqiromiseA An operating system abstraction and protection layer 
100 will provide an additional, programmatically controlled barrier between appHcations 50 to 
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remove most appUcation level interactions. Disposed between the application SO and operating 
system 10 the operating system abstraction and protection layer 100 selectively allows 
cbanges directly to the opexating system 10, versos containing the change within the context of 
the running application. For one exaixple, in "Vl^dows-based systems, alt operatkms to the 
Windows Ke^stry are typically done through the Win32 API As e>qilained below, system 
functions like QueryRegBx and GdProfileStiing can be hooked so that each time tiiey are 
invoked, another fimction or application intercepts the caD. The Operating System Guard 100 
of the present invention wiU hook eadi appropriate API fimction to service the request, if 
made by an application bdng actively managed or if made by an application against a 
configuration item bemg actively managed. In tiii5way,Tmles5e9q)fickly configured to do sot, 
the present invention can create the appfication environment widiout making any actual 
dianges to the end-iiser's system Also, any modifications made at mn-time by the 
application can be perssted or removed easily. 

As ixsed herein the term "Operating System Guard" defines a layer between a 
running application and the operating system of a target coiiq>xiter or client coi]q)uter that 
provides a virtual environment in which an application noiay run. This virtual 
enviromnent has several purposes. First, it prevents a running application firom making 
changes to the client corqputer. If an application attenqits to change underlying operating 
system settings of a client compvtex^ such settings are protected and only '"imade" in the 
virtual environment. For examplCy if an application attQinpts to change the version of a 
shared object like MSVCRT.DLL, this change is localized to the application and the code 
resident on the cUent conyiuter is left untouched. 

Second, the invention presents an environment to a running application that 
appears to be an installation enviromnent without performing an installation^ and is thus a 
'^seudo installation" or 'installation-like." All of the settings are brou^t into a virtual 
environment at the time the application being served nms, or just-in-time wiien the 
application needs the particular setting. For example, if a conoputer program such as 
Adobe Photoshop® expects to see a set of Windows Registry entries under 
HKEYJLOCAL_MACHINE\Software\Adobe and they are not tiiere on the client 
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coixputer since Photosbiop was never installed, a system made in accordance with this 
aspect of the present invention will "show" those registry entries to the Photoshop 
progranuning code exactly as if they were resident on the client conqpntet. 

Nbxt, the invention prevents information that may exist on the client/dsers 
machine from interfering with or modifying the behavior of an application. For exanQ)le, 
if the user has ahready existing re^stiy entries under 

HKEYJLOCAL_MACHINE\Software\Adobe 
for an old^ version of Photoshop, but now wishes to operate a newer version, these 
entries can be hidden from the new application to prevent conflicts: 

Finally, the present invention unlocks application behavior that may not exist as 
the application is currently written. It does this through the ability to dynamically change 
the virtual envirotmient according to administrative settings. For exanq)le, in a typical 
instance of an enterprise software application, a client application may expect to read a 
setting for the address of the database to v^diich the us^ should connect from a setting in 
the registry. Because this registry key is often stored in HKEYJLOCALJVIACHINE, the 
setting is global fi>r the entire client con^uter. A user can only coimect to one database 
without reinstalling the client, or knowing how to modify this registry key, and doing so 
each time they wish to run the application. However, by in^lementing the present 
invention, two instances of the application may. now run on the same client computer, 
each connecting to a different database. 

CONTEXTS 

In providing this ftmctionality, each application is able to run in a private context 
within the system To the application, it has its own private view of what the system 
looks Bke and its behavior. The present invention provides this by its inherent nature. 
Referring to FIG. 2, two separate applications 52,54, or two instances of the same 
application (50 illustrated in FIG. 1), can be provided private contexts in which they will 
appear to have sqparate or differing copies of system services, configuration and data. In 
the preferred embodiment, this is the default behavior of the ssystem 
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By extending this concept, the Operating System Ooard 100 of Hie present 
iavention can also provide shared, controlled contexts in which two or more applications 
52,54 can sbare some or all of fheir virtual setthigs. This is ixq}oitant for application 
suites such as Aficrosofi Office, or for applications that peifoim differently in the 
presence of other appfications. For example, many applications use Microsofi Word as 
an engine for doing ^foiI Merge or document creation fimctioriality. The applicatidn 
must know about the installation or presence of Word and be able to tap into its 
fimctions. In the preferred embodiment, two instances of the same application will share 
a angle context by default, while two separate applications will maintain private 
contexts. Referring to FIG. 3, the two applications 52,54 can run while the Operating 
>ystem Guard 100 provides a shared view of the available system resources. 

)£SIGN 

As illustrated in FIG. 4, the Operating System Guard is conq)rised of the 
bllowing subsystems: core 102, configuration manager 104, file manager 106, shared 
ibject manager 108, device manager 110, font manager 112, process manager 120, 
trocess environment manager 114, loader 116, and recovery manager 118. With the 
Kceptton of the core 102, the process manager 120, and the loader 116, all other 
ubsystems are elements of the Vhtualization System described in fiuther detail below, 
[he core 1 02 is primarily re^onsible for managing applications and their context as 
tefined by the configuration files. 

The process manager 120 provided by the Operating System Guard allows the 
me 102 to be informed of any process or thread event that may be of interest. It also 
provides an abstraction layer to the operating system-dependent implementations for 
Danaging a process space and handling thread processing. Processes may be grouped 
ogether into application bundles. An application bundle is a group of processes ^^hich all 
hare their virtual resources with each other. For example, Microsoft Word and Microsoft 
ixcel may want to share the virtual registry and virtual file system to be able to work 
ogether 'as an application suite. The process manager 120 calls these application bundles 
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"applications". The informatioii about an application exists iintil the process manager 120 
is told to release the appfication. If another process needs to be loaded into the application 
bundle, it may do so as long as the application has not been released. 

The loader ^subsystem 1 16 of the present inventioa is used to allow virtoal 
environments to be transferred into and out of the running system. Eacb of the 
Vbrtualization Subsystems is capable of serializing its configuration for the loader 116, 
and retrieving it through the reverse process. In addition, the loader 116 is capable of 
staged loadmg/unloading and combining the results of individual stages into one single 
environment descnptiQa 

REGISTRY AND CONFE6DRATION 

Applications requhre varying amounts of configuration information to operate 
propoly. Anyvrfiere fiom z^o to thousands of configuration records exist for which an 
application can read its configuration On Windo\^, there are two common places for 
configuration inJfoimation, the Windows Registry and system level iiojtialization files 
win.iniandsystem.ini la addition, the \WIhroOWS\SYSTm directory is a common 
place for applications to write application specific configuration or initialization files. 
Applications will also use configuration or data files in their local application directories 
to store additional configuration information. Often this infiirmation is difficult to deal 
with, as it is m a proprietary format. On platforms other than Windows, there is no 
equivalent of the Registry, but common directories exist for configuration information. X 
Windows has an app-defaults direaory. Macintosh has the System Folder, and other 
operating systems will have corresponding elements. It is important to note that on most 
UNIX systems, each individual application 52,54 will most often store its own 
configuration 152,154 locally, as seen m FIG. 2. 

The present invention, in one embodiment, includes a virtual Windows Registry 
.conq)onent, which will provide a fijll fimction registry to an application, but prevent 
modification to the underlying system registry. All keys that an application e)q)ects to 
access will be present, but may only exisft in the virtual registry. In this way, the 
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Operating System Guard 100 of the present invention and ihe Windows Registry form a 
twO"Stage process for accessbg the registry. If an appficatiGn needs access to a key, it 
will qaecyfhe Registry, llie Operating SysteniGoardwiQ respond with the key an 
vabieifit knows it. Odierwise, it wiU.aflow the request to pass through to the Windows 
Registry. If an atten^t is made to modify the value, the Operating System Guard will 
allow the modificati0n to occnr to itself only. The next time the application accesses the 
key, it wBfl be present in the Operating System Guard and the request will not flow 
tibrough to the real Registry, leaving it untouched 

The keys that the Operating System Guard uses are speciJBed in three separate 
sections. These (^crating System Guard keys are specified as commands in these 
sections to modify an existing key, delete the presence of a key, or add a new key to the 
registry. In this way, the virtual registry can appear exactly as the system intends. This is 
in^ortant as the presence or absence of a key can be as iniportant as the actual vahie of 
the key. 

In the preferred embodiment, the Operating System Guard first loads a data file 
that contains basic registry entries for the application. Then a second data file is loaded 
that contains the user's preferences. Finally, the Operating System Guard can optionally 
load a set of keys that include policy items that the user is not allowed to override. The 
three files load on top of each other with duplicate items in each file overriding items in 
the file before it. The first time a user runs an application, the second data file will not 
exist because there will be no user-specific information, only application defaults. After 
each session, though, the Operating System Guard will save the user's changes, 
generating that second data file for use in future sessions. 

Configuration files can be modified in two ways. First, the file can be edited 
directly by an application. In this scenario, the Operating System Guard File subsystem 
described below will address the modification made to the file. Second, in the preferred 
embodiment, an application can call the Windows API family of calls GetProfileString, 
WriteProfileString, or others to modify these files. lo this case, the Operating System 
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Guard of the present invendon performs exactly as described above intercepting these 
calls and servicmg them from ^dthin. 

SHAK£I> OBJECTS 

Many con^onents used by operating systems and running applications are shared 
across several applications or instances. In general, this is a very good idea. B saves disk 
space, not requiring many copies of the same file. B also provides the ability for 
operating system vendors and third parties to create and distribute libraries of commonly 
used code. On the Windows platform. Dynamic Link Libraries, DLLs, are often shared 
within and across applications. On other platforms, the problem is the same. On the 
Madntosh, BMITs and other system coinponents are loaded for applications. These 
con^onents can have many versions, of M*ich only one is used at a time. On UNK 
systems, dyoamic shared objects, e.g., "so" library files, are used by applications to 
speed load time, save disk space, and for other reasons. Many programs use the de&ult 
'Tibcso." However, this library file is typically a symbolic link to some version of itself 
such as Kbc.soJ. Jn practice, this feature has created havoc. These shared cong)oiients 
have often gone through revision, with many versions of the same con:q)onettt available to 
be installed Application authors have found then: software to work with potentially only 
one or some of the versions of the shared con:q>onent. Thus, in practice, applications 
typically install the version they desire, overwriting other present versions. This 
potentially causes defaults in other applications running on a system 

On Wmdows 98, Windows 2000, Microsoft has created the Windows Protected 
File System (WPFS).to allow system admmistrators to create a file called 
XXXX.LOCAL in the base directory of an application, where XXXX is the executable 
file name without the extension. This causes the Windows Loader to alter its method of 
resolving path references during LoadLibrary executions. This, however, is not sufficient 
to cpn5>letely solve the problem. First, setting up the XXXX file is left to the knowledge 
of the system administrator, ^Mch varies widely. Second, a conq)onent version must 
undergo a rewind back to the origmal, then install this component in the local directory, 
and then create the ".LOCAL" file. This is not a straightforward process for any but the 
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most basic co]x^)0]leIIts placed in Wt^roOWS\SySTEM. Aliso, this solutiooti does not 
cover all of the needed fiinctionality. Doling Loadlibrary, Windows uses dififereirt path 
lesotution semantics dreading on wlietiier the con^onent was resolved as a result of an 
explicit or tixq>licit LoadIibrary,.and also i?«die11ier a Registry Key exists indicating that it 
is a named, or.weD-lcnowo, DLL Jn this case, the LoadLibraiy call will always resolve 
to (he WINDOWS\SySTEM directoiy. 

DLLs and other shared con^qponents also retain reference count semantics to 
msure that a con^)onent is not touched unless no running applications refer to it. tx 
practice, only applications from the operating system vendor and the operating system 
itself have done a good job of obeying this protocol 

As a general role, it is desired to have a shared object always resolve to the 
correct conq>onent. To provide this fimctionality it is required to understand the version 
of a component, or range of versions, that an application is able to fimction vsdtL Then, 
^en the application is to be run, the present invention ^ould ensure that the corq^onent 
is resolved correctly. Jt is acceptable, in the present invention, to automate the use of 
WPFS or other operating system prorvided capability, if dedred. la this case, it is 
necessary to detect needed conyonents and place them in the local file system This is 
more cbnqilex than just watching installation, as an installation program will ofien not 
install a con9)onent if the required one is aheady there. 

It is de^ed to identify a method to ensure that named objects are also loaded 
correctly. On the Windows platform, MSVCRT.DLL is a ^gnificant culprit within this 
problem area. If multiple versions of this object are maintained, the aforementioned 
Registry key can be dynamically changed, allowing the LoadLibrary fimction to resolve 
the correct conq)onent version. Another reasonable method of ensuring correct 
conqionent loading is the dynamic editing of a process environment to use a valid search 
path. This search path will ensure that a local con9)onent is resolved before -u system 
wide conq>onent Another posdble method for resolution of the correct shared object is 
through flie use of symbolic Imks. A symbolic link can be made for a shared conoponent. 
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vMdx is resolved at nm-time by the computer's £le system to the needed con^oneat. 
Finally, the actual openAread/close requests for information from a shared object's file • 
can be intercq^ted by the present kvention and reqyonded to dynamically &r the coirect 
version of the file TvMch may exist on &e local system or within the mvention's 
subsystems. 

Several fecial forms exist QntheWmdowsplatfoim, OLE, ODBC, MDAC, ... 
as wen as a nuniber of other vendor specific conq)onents, are wdttea to be shared 
globally among several or all running processes. la the case of OLE, going as far as 
faring data and memory space between s^arate processes. OLE prevents more than 
one copy of itself naming at a time, as do wsmy of these components. OLE also has 
many bugs and features requiring a specific version to be loaded for a specific 
application. In the present invention, an application is able to load \;sdtLatever version of 
OLE is required, still enabling the shared semantics with other conqponents using tiie 
same version of OLE. 

In general, unless specifically configured as such, sliared objects sbonld be loaded 
privately to ensme conflict prevention. Nothing about the method used to allow a 
cont^onent to be loaded privately should prevent it firom being unloaded cleanly or 
correctly loading &r ano&er software application, wdieiher being activety managed by 
the Operating System Guard or not. In addition, if the system crashes it is required to 
recover fiomthis crash to a clean state, not having overwritten or modified the 
underlying operattng system. 

fILES 

Many applications use data files within the application to store configuration 
entries or other application data. The present invention provides a virtual file system 
much like the virtual registry described above. Before the application starts, the present 
invention can load a list of file system changes, including files to hide and files to add to 
the virtual environment or files to redirect to another within the virtual environment. 
Whenever the application accesses or modifies any files, the Operating System Guard 
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checks if the jSle must he redirected, and if so, in the preferred embodiment redirects the 
request to a location speciJGed in the Operating System Guanl configuration. 



If an application tries to create a new file or open an existing file for writing on a 
user's local drive, the Operating System Guard must ensure that the file is actually 
created or modified m the redirected location. If the application is reloaded at a later timie, 
this file mapping must be reloaded into the Operating System Guard virtual environment 
When the request is to modify an ejdstkg file, which resides on a user's local drive, the 
pperatmg System Guard must copy the file in question to tiie redirection point before 
continuing with the request. The redirected files may not be of the same name as the 
original file to ensure safe mapping of file paths. In the preferred embodiment, INI files 
are handled in this way to offer maTcimum system security while allowing maximum 
application conq)atibility. . 

The present invention is particularly usefiil for applications delivered over a 
network In such in^lementations it is inoportant to understand that software applications 
are made pf several kinds of data, where the bulk of the files a software application uses 
are most preferably mounted on a separate logical drive. Configuration, including both 
file based and registry based, can be user g>ecific and system wide. The application 
delivery system used should mark each file for which of these types any file is. This 
information provides hints to the pperatmg System Guard system to act on appropriately. 

BEVICXDBIVERS 

Many applications use device drivers ox other operating system, level software to 
implement some of its fimctions such as hardware support or low leved interactions 
directly with the operating system 6i the present invention, the Opejrating System Guard 
will provide the capability of dynamically, and as possible privately, adding and 
removing these conq>oxients to an application's virtual ^vironment:. 

Many device drivers are built to be dynamically loadable. If ' at all possible, it is 
the preferred embodiment to load all device drivers dynamically. If a device driver 
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requires static load at boot time, the user must be presented with this fcaowledge before 
nmning the application. Once the sy^emhas rebooted, the application should contiraie 
from where it left off However, a large p«centage of device drivers are not dynamically 
imloadiible. Although it is preferred to dynamically raiload the driver, if this cannot be 
acconqilisihed the driver will be marked for removal on the next reboot, and the user 
should be made aware of this. If the application is nm a second time before the next 
reboot, the system should remain aware of the presence of the driver and not attexx^t a 
second installation, waiting for temunation to remark the con^ionent removable at next 
reboot. 

It is important to characterize the base amilarities and diflferences, as fliey exist 
fer each device driver clas% to ensure the present invention can correctly fimction. It is 
not truly desired to load and unload device drivers for system hardware that is constamtfy 
present. It should be understood that aMhou^ this is not a prefared embodiment^in 
terms of programming ease, it is wiflun the scope of the present invention and may be 
required for q)ecific reasons, such as the restriction in licmsmg agreements for 
applications that are delivered and run using the present invention. 

On non-Microsofi platforms, device drivers are typically handled very differently. 
Macmtodi systems sappoit both static and dynamic drivers, but they are all installed and 
removed through the same method. linking with the Madntosh system folder will 
provide the necessary support For UNIX systems, device drivers most typically require 
a modification to the running UNK kernel, followed by a reboot. This process can be 
very conqilex. hi the preferred embodiment, this process is automated; including 
resetting the kernel once the application is con5)lete. The general parameters of the 
process are the same as that described above &r Windows applications, the actual process 
steps of compilation and persons femiliar with such operating systems can carry out 
reboot. 



-13- 



wo 02/093369 



PCTAJS02/15378 



Finally, those of skill in the art wll understand that it is dearaUe to be able to 
recover and remove drivers across system failures. Whatever data or processes necessary 
to retain system integrity are therefore a preferred embodiment of the present invention. 
Those of skill in the art will also appreciate that all types of device drivers imght not be 
conveniently or eflGLcientfy provided via the present invention, most particularly those 
associated widi permanent hardware attached devices. 

OTHERITEMS 

In the present invention, it is recognized that there are several components of the 
invention, the behavior or preseaice of which is diJBFerent on abemate opo-atmg systems. 
These con^onents include fonts, processes, environment variables, and others. 

Some applications require fonts to be installed in order to perform correctly. Any 
fonts required will be specified in the Operating System Guard's configuration file. The 
Operating System Guard will enable these fonts prior to running the application and if 
necessary remove them afterwards. Most systems have a common area for storage of 
fonts in addition to a process for registering them or making the system aware of their 
presence, the Operating System Guard wiU utilize these available methods. 

On Windows, a font is copied to the \WINI)OWS\FONTS directory. This 
however does not guarantee that the font is available to the running program In the 
preferred embodiment, if the program uses the Windows API to access fonts, the font wdll 
need to be registered with a Win32 API call such as CreateScalableFontResource/ . 
AddFontResonrce. This will insert the font into the system font table. Once con5)lete, 
the Operating System Guard can remove the font with another appropriate API call like 
RemoveFontResonrce, then remove the file from the system. Asanattemate 
embodiment, the Operating System Guard could hook the API Amotions as described in 
the virtual registry method. In addition, the Qperatiag System Guard can use its File 
subsystem to avoid placing the actual font file in the running system 

On Maciatosh, the process is extremely similar and based on files ill the 
Macintosh system folder and registration activation. On UNIX, however, the process is 
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dependent iipon the application. Most typically, font resources are added to the system as 
regular files resolved in the proper location, so tiiey can be accessed by name. Vfilii 
many Motif systems, a font description needs to be placed into a font resource file, wUdi 
vnH allow^e font to be resolved. The Motif or X application can invoke the font either 
through fhe resolution subsystem or by a direct call. Recentiiy, many Motif and CDE 
based systenous utilize Adobe scalable postscnpt fonts. These fonts need to managed 
through the Adobe type management system. There are exceptions, however, and as 
stated above, there are alternates to the Windows or other operating system default font 
management systems. Hie Adobe Type Manager provides some alternate inter&ces for 
this process, as do other third party type naanagement systems. In most cases it ^ould be 
decided wheih^ to SEtppott the inter&ce or ignore it. The purpose of Operating System 
Guard is not to jxrovide a universal layer for all these systems, only to do so for the 
operating system's own'^bsystem 

Many applications require environm^t variables to'be set. This is most common 
. on UNIX systems, but is also Heavily used by software, which was originally written on 
UNIX and ported to the Windows operating systems. Applications on the l?\^dows 
operating systems heavily rely on the DOS PATH environment variable and often set 
their own application specific entries. On the Windows 9x/Me environments, there are 
many enviromnent settings, which are applicable as at its core is the DOS subsystem. If 
an application requires the presence of specific variables, or values to be set in existing 
. environment variables, the req[uired enviroimient variables will be specified in ib^ 
Operating System Guard's configuration file. The Operating System Guard will set these 
variables for the application's main process when it is launched. As applications do not 
typically change environment settings as they operate, fhe virtual environment will not 
trap these calls, nor will it provide the full conoplement of fimctionality that the regjkry 
and configuration subsystem does. 

RECOVERY 

In some cases shown in the previous sections, actual modifications must be made 
to the operating system This is fiequeut with device drivers and fonts. Inaddidon, 
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changes can be made to the \dTtual envfaroimient that need to be persisted and available 
the next time an application is nm. It is required that the Operating System Guard system 
be able to recover from changes to the system, removing the change from the system at 
its eadiest possible opportonity. Alternately, if the system crashes during an 
application's execution, the Qperatmg System Guard ^oidd track enough information, to 
remove any change to the system if it is rebooted or oth^wise, and should track the 
dianges made to the virtual environment. In the preferred embodiment, this is 
implemented as a transaction log, but can in other embodiments be done as some other 
sbnilar component, vMsii can be read on system startup so that changes can be backed 
out 



CONTROLUSG VIRTUALEZATION 

An xa^>ortan^ aspect of the invention relates to control of the many ficets of 
virtualization \;sdiich the Operating System Guard is capable o£ In the preferred 
embodiment there exists an instrumentation program able to ascertain the coirect aspects 
of a software system to control Also included is a method to allow admioistrators and 
end users to view and modify those items to be virtualized by the systeniL 

In the automated program, the application to be controlled is observed in order to 
gauge the aspects of control The automated program is capable of performing this task 
during the installation process of the application, during run-time of the application, or a 
combination of botk In the prefwed embodiment, the Operatiog System Guard is 
embedded in a wrapper application. Post installation, or after one or many uses of the 
software, the wrapper appKcation will query the Operating System Guard for a detailed 
list of all of its actions. From this list of actions, the wrapper application will create the 
configuration files required to load and operate the Operating System Guard on 
subsequent uses. 

If used as part of the installation process, the Operating System Guard, in the 
preferred embodiment, will act as a virtual layer allowing the installation to be entered 
into its environment only. After the installation, all of the files, settings, et. aL can be 
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dumped for reload later. Jn this way» the installation will leave die onginal system intact 
and win liave automatically created the necessary configuration files. AVhen used during 
use of the application, the Qperatmg System Guard is able to record either differential 
modifications to the envkonment, or recodify the configaration files. 

The Operating System Guard will pass its infimnation to the wrapper application 
for post-processing. In the prefenred embodiment, in addition to.the automatic entries 
that the system can create, the wrapper application is programmed with operating system 
specific and application or don:iain specific knowledge. This knowledge is used to alter 
the output of the process to reflect known uses of configuration items or other ortdes. In 
the preferred embodiment, a rules-based system is enoployed to con^are observed 
behaviors with known scenarios in order to effect changes to die coding. 

The wrapper application is also used as a viewer and/or editor for the 
configuration output of the process. This editor, in the preferred embodiment, enables a 
system administrator to add, edit, or delete items or groups of items fiom tilie 
con^;aration. In observiag tiie configuration through the editor, the administrator can 
also make replicas of the configuration, changing specific items as needed to effect 
application level or user custom dianges, 

Refiling now to FIG. 1, an embodiment of the present invention is ilhistrated 
fimctionally. In this embodiment, two sets of application/user data 60 are illustrated. 
The Operating System Guard 100 keeps the two instances of the application 50 firom 
interfering v\ath one another, hi addition, as explained above, the operating system guard 
100 serves as an abstraction layer and as such collects commands and communications 
between the application software 50 and the actual operating system 10 of the client 
conq)uter. As illustrated graphically by the arrows, certain commands are between the 
Operating System Guard and the software application, this is in distinction to typical 
installations where these commands wonld instead be acted upon by the operating system 
itself resulting in changes to the client computer that might not necessarily be wl^at the 
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operator ioteaded. On the other hmd^ other commaiids pass through the Operating 
System Guard and are thea transferred to the Operating System itsel£ 

While this invention has been particular^ shown and described with references to 
preferred embodiments thereoi^ it will be imderstood by tiiose skilled in the art that 
. vanous changes in £brm and details may be made therein without departing fiom the 
scope of the invention encompassed by the appended claims. 
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What is claimed is: 

1. A system for creaiting an application software environment without changing an 
operating system of a cUent computer, the system conq^iising an operating system 
abstzacdon and protection layer, i^eretn said abstraction and protection layer is 
inteiposed between a naming software application and said operating system, whereby a 
virtual environment in which an application may nm is provided and application level 
interactions are substantially removed. 

2. The system of claim 1, wherein changes directly to the operating system are 
selectively made within the context of the rmming application. 

3. The system of claim 2, wherehi the abstraction and protection layer dynamically 
changes the virtual environment according to administrative settnigs. 

4. The system of claim 1, wherein the system continually monitors the use of siiared 
system resources and acts as a service to apply and remove chaiiges to system 
con^onents. 

5. The system of claim 1, wherein the operating system is a Windows-based operating 
system, and wherein aU operations to the Windows Registry and .ini ffles are through the 
Wia32 API, the system further conprising a means for hooking fimctions, whereby each 
time said functions are invoked another function or application intercepts the call 

6. The system of claim 5, \^erein the system hooks each appropriate API function to 
service a request whether mad^ by an application run from a server or if made by an 
applicatioh against a configuration key beiag actively managed 

7. The system of claim 1, wherein said operating system abstraction and protection layer 
manages the integration of multiple instances of an application by recognizing hov\^.many 
instances of an application are running. 
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8. The system of claim 7, herein said operating system abstraction and protection layer 
avoids making changes on startup and shutdown imless there is only one application 
instance nmning. 

9. The system of claim I, wherein said operating system abstraction and protection layer 
preseaits an environment to an application that appears to be an installation enviropment 
without pecfonning an installation, wbereby a '^sendo installation" is created in which 
all of the settings are brought iato a virtual environment at the time the application runs. 

10. The system of claim 9, fbrdier conqirismg a means fiir preventing information on the 
client conqputer fiorn interfering or modifying the behavior of an application. 

1 1. The system of claim 9, farther con^rising a means for dynamically changing the 
virtual environment according to administrative settings. 

12. The systeni of claim 9, wherein more than one instance of a smgle software 
application runs on the same client computer, and wherein each of said more than one 
instance connects io a different database 

13. The system of claim 12, wherem shared, controlled contexts are provided in which at 
least two of said instances of a single application share one or more virtual settings. 

14. The system of claim 1, fiirther cocqnising a device driver monitor that receives 
instractions at the time of installation for a particular application. 

15. The system of claim 1, finiher con^rismg a virtual Windows Registry con^onent to 
provide a ftill fimction registry to an application, bxrt prevent modification to the 
underlying system registry. 
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16. The system of claim 1, \^erem the operating system abstraction and protection layer 
lesponds ^wkk a key and its value if said key and value are stored ^within the operating 
system abstraction and protection layer, if not stored, the operating system abstiraction 
and protection layer allows the request to pass through to the Windows Registiy. 

17. The system of claim 16, wherein if an attenq>t is made to modify the value of said 
key, the operating system abstraction and protection layer allows the modification to 
occur to itself only. 



-21- 



wo 02/093369 



1/2 



PCT/US02/15378 



Application/User Data 



ApplicatiDn 



i; i\ 



Shared Resourpeii 



O 

01 

o 



AppJlcattonAJser Data 



AppUcslton 



Shared Resources 



Trusted Shared Resources 



OSGuard 



EH 



Operating System 



6(3 
5* 



Application 1 
Instance 1 



\ppDcation 1 
Instance 2 



Operating System Guard 



^'^\^ ■ Application Configuration 



/cTO 



f'6-Z 



Appfication ConfjguraHon 



System Configuration 



Private 
Contexts 



System Configuration 



Svstem Servfees 



System Services 



wo 02/093369 



2/2 



PCT/US02/15378 



AppDcatbn 1 
Instance 1 



Application 1 
instance 2 



Operating System Quard 



■si 



yxppBcation ConfigurBfion 



Shared 
Context 



System Sendees 



System Configuration 




/oc? 



INTERNATIONAL SEARCH REPORT 



Intel 



m^^ial Application No 

PCT/US 02/15378 



A. CLASSIFICATION OF SUBJECT MATTER . 

IPC 7 G06F9A45 G06F9/44 606F15/163 G06F17/30 



According to International Patent Classification (IPC) or to both national classlflcafion and IPC 



B. RELDS SEARCHED 



l^Ainlmum documentation searched (classification system followed l:y dassDIcdton symbols) 

IPC 7 G06F 



OocumenlaUon Gearohed other than minimum documentation to the extent that such documents are Included (n the flekfe searched 



Electronic data base oonsulled during the International search (name of data base and, where practical, search terms used) 

EPO-Internal , INSPEC 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category * Citation of docunrant. with indication, where appropriate, of the relevant passages 



Retevant to dalm Na 



us 5 752 005 A (JONES CLAY LAMOYNE) ■ 

12 May 1998 (1998-05-12) 

abstract 

column 2, line 35 - line 60 

US 6 026 402 A (VOSSEN JOSEPH K ET AL) 
15 February 2000 (2000-02-15) 
column 2, line 24 - line 30 
column A, line 57 - line 67 
column 5, line 31 - line 38 
abstract 

MARK RUSSINOVICH AND BRYCE COGSWELL: 
"Windows MT System-Call Hooking" 
DR. DOBB'S JOURNAL, 
January 1997 (1997-01), page 42,44,46,82 
XP001096512 
the whole document 

-/-- 



1-17 



1-17 



4-6 



m 



Further documents are listed in the continuation of box C. 



Patent family members are listed In annex. 



^ Special categories of dted documents : 

*A' document defining the geiieral slate ot the art which Is not 
considered to be of particular relevance 

*E* earBer document but published on or after the International 
filing date 

'L* document which may throw doutrts on priority claim(5} or 
which ts cited to establish the put>ncat{on date of another 
dtalion or other spedal reason (as specified) 

*0* document referring to an oral disclosure, use, exhibition or 
other means 

*P* document published prior to the inlernationa} fiilng date but 
later than the priority date claimed 



*T* later document published after the International fUlng date 
or priority date and not In conflict wilh Ihe application but 
cited to understand the principle or theory underlying the 
invention 

*X* document of particular relevance; the dalmed Inventbn 
cannot be considered novel or cannot be considered to 
Involve en inventNe step Virhen the document is taken alone 

"Y* document ot particular relevance; the claimed invenlton 
cannot be considered to Involve an inventh^e step when the 
document Is combined with one or more other such docu- 
ments, such oomblnalion being obvious to a person sIdBed 
In the art. 

document member of the same patent family 



Date of the actual compleiion of the international search 



2 September 2002 



Date of mailing of the international search report 



30/09/2002 



Name and maling address of the ISA 

European Patent Office, P.a 5818 Patentlaan 2 
NL-2280HVRIjswlik 
TeL (+31-70) 340-2040. Tx. 31 651 epo nl, 
Fax: (+31-70) 340-3016 



Authorized officer 



MOller, T 



Foim PCT/ISAQ1D(seeindsheal)PiiV 1892) 



INTERNATIONAL SEARCH REPORT 



Inteir^^ial AppdcaUon No 

PCT/US 02/15378 



^(Continuation) DOCUMENTS CONSIDERED TO BE RELEVANT 



Categofy' 



Citation of document. wRh Indtoatkm.wttere approprlale, of the relevant passages 



Relevant to clalnr) No. 



UO 00 46685 A (AHN JAI WAN ;S0N6 DONG HO 
(KR); SOFTONNET CO LTD (KR)) 
10 August 2000 (2000-08-10) 
abstract 

page 7, line 8 - line 11 
page 7, line 30 - line 36 
page 11, line 12 - line 20 
figure 5A 

US 6 023 721 A (CUMMINGS CHRISTOPHER R) 
8 February 2000 (2000-02-08) 
abstract 

column 2, line 20 - line 55 
column 3, line 44 - line 62 
column 4, line 35 - line 60 

EDOUARD BUGNION, SCOTT DEVINE AND MENDEL 
ROSENBLUM: "Disco: Running Commodity 
Operating Software on Scalable 

Multiprocessors" 

PROCEEDINGS OF THE 16TH SYMPOSIUM ON 

OPERATING SYSTEMS PRINCPLES (SOPS), 

•Online! October 1997 (1997-10), pages 

1-14, XP0D2211769 

Saint-Malo, France 

Retrieved from the Internet: 

<URL : ftp : //www-f 1 ash . Stanford . edu/pub/h1 ve 

/SOSP97-disco.ps> 

'retrieved on 2002-08-30! 

page 1, left-hand column, line 39 - line 

45 

page 2, right-hand column, line 1 - line 
10 

page 6, right-hand column, line 25 - line 

32 

ROGUE WAVE SOFTWARE: "Copy on Write" 

WEBSITE OF ROGUE WAVE SOFTWARE, 'Online! 

1996, XP002211770 

Retrieved from the Internet: 

<URL : http ://www. tacc . utexas . edu/resources/ 

user_gu1dGs/crayc-H-tools/toolsug/cop«3018. 

htm> 'retrieved on 2002-08-30! 

the whole document 



9-14 



13 



15-17 



15-17 



INT|yNATIONAL SEARCH REPORT 

btforroallon on patent family membefs 


lntem^|ial Application No 

PCT/US 02/15378 


F>atenl document 
cited In search report 


Publication 
date 


Patent iamlly 
imml>er(s) 


Publication 
date 


US 5752005 


A 


12-05-1998 


NONE 








US 6026402 


A 




NONE 








UO 0046685 


A 


10-08-2000 


AU 
CN 
EP 
UO 


2463700 A 
1354857 T 
1163599 Al 
0046685 Al 


25-08-2000 
19-06-2002 
19-12-2001 
10-08-2000 


US 6023721 


A 


08-02-2000 


NONE 









Fofm PCT/ISA/210 (patent tamlV amex) (Juli^ 1992) 



